Telegram Group & Telegram Channel
سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev
Please open Telegram to view this post
VIEW IN TELEGRAM



tg-me.com/hasanxdev/136
Create:
Last Update:

سوال جالبی از من پرسیده شد جهت افزایش دانش شما عزیزان به اشتراک گذاشتیم ❤️

🤔 سوال توسط amirmohammad Fathollahi پرسیده شد:
من برای api gateway دنبال best practice هستم با ocelot
هرچی ویدیو میبینم صرفا در حد اینه route کنه
ولی راجع به معماری و هندل کردن چندین پروژه حرفی نزدن
اگه کسی منبع خوب یا سمپل کد میشناسه معرفی کنه ممنون میشم
توی معماریش چه کار هایی میکنن چه چیز هایی رو بهش میسپرن
آیا صرفا فقط برای reverse ازش استفاده میکنن یا rate limiting و authentication هم بهش میسپرن
بیشتر سوالم راجع به معماریش هست


💡 جواب:
در واقع API Gateway رو یا باید خودمون پیاده سازی کنیم یا از ابزارهایی مثل Kong استفاده کنیم.
اگر خودمون پیاده سازی کنیم طبیعتاً دسترسی کامل به همه چیز داریم ولی Kong مثلا بهمون یک Dashboardهم میده و شاید در یک سری جاها به اندازه یک API Gateway اختصاصی دست آدم باز نباشه.

حالا وقتی میخواهی خودت پیاده کنی Per Environment باید Config های Routing خودت‌رو داشته باشی یعنی روی Develop با Production باید Configهاشون فرق داشته باشه چونکه آدرس ها در Develop Local و Production قطعا متفاوت هست.
یکی از Best Practiceهایی که معمولا در API Gateway ها در نظر می‌گیرند Code Less می‌کنندش یعنی هیچ کدی داخلش نمی‌گذارند و واقعاً شبیه Gateway عمل میکنه، بدون هیچ Business Logic خاصی.

درباره Rate limit باید بهتون بگم که Trade-off زیاد دارد!
یک موضوع infrastructure ای هست یعنی در لایه Application پیاده نمیشه چون Bottleneck برنامه میشه و اگر مشکل داشته باشه میتونه برنامه بندازه یا کند کنه همچنین میتونه single point of failure باشه.
پیچیدگی Rate Limit زمانی هست که چندین Instance از برنامه ما بالا باشه به همین دلیل Application Layer جای خوبی نیست براش اما اگر برنامه شما اینقدر کوچک هست که یک Instance فقط از API Gateway دارد، بنظرم دوباره فکر کنید آیا واقعاً به microservice نیاز داشتید یا نه!
حالا فرض میکنیم که شما به API Gateway نیاز داشتید و Rate Limit هم قرار هست پیاده کنید بنظر من بهتره در لایه Application خودتون پیاده سازی بشه و اگر واقعاً یک چیز نیاز دارید که خیلی Global باشه و زیرساخت ندارید مثل تیم DevOps بنظرم API Gateway جای خوبی هست

اما در کیس Authentication خیلی Trade-off نداریم!
کنترل رو می‌سپارن به خود Application ها، همان‌طور که گفتم خیلی سعی میشه API Gatewayها Code Less باشن فرض کنیم سرویس A با مدل AModel احراز هویت میشه و سرویس B با مدل BModel و این میتونه در API Gateway پیچیدگی ایجاد کنه و از نظر Separation of Concerns باید API Gateway یک Gateway بمونه واقعاً
به این دلیل که Authentication میتونه خیلی پیچیدگی ایجاد کنه من حداقل ندیدم جایی احراز هویت رو روی Gateway پیاده کنند، ولی این کار نشدنی نیست.
در بعضی از مدل های احراز هویت نیاز هست که Token برای سرویس اصلی که Authentication رو پیاده سازی کرده ارسال بشه و اگر ما در API Gateway احراز هویت رو پیاده سازی کرده باشیم این میتونه باعث بشه API Gateway خودش گلوگاه باشه که درخواست‌ها رو کند کنه و وقتی کندی در سیستم میبینیم نمی‌دانیم سرویس واقعاً مشکل دارد یا API Gateway

اگر نظری دارین در کامنت ها برام بنویسید 👇
Channel: @hasanxdev

BY Code With HSN


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/hasanxdev/136

View MORE
Open in Telegram


Code With HSN Telegram | DID YOU KNOW?

Date: |

Among the actives, Ascendas REIT sank 0.64 percent, while CapitaLand Integrated Commercial Trust plummeted 1.42 percent, City Developments plunged 1.12 percent, Dairy Farm International tumbled 0.86 percent, DBS Group skidded 0.68 percent, Genting Singapore retreated 0.67 percent, Hongkong Land climbed 1.30 percent, Mapletree Commercial Trust lost 0.47 percent, Mapletree Logistics Trust tanked 0.95 percent, Oversea-Chinese Banking Corporation dropped 0.61 percent, SATS rose 0.24 percent, SembCorp Industries shed 0.54 percent, Singapore Airlines surrendered 0.79 percent, Singapore Exchange slid 0.30 percent, Singapore Press Holdings declined 1.03 percent, Singapore Technologies Engineering dipped 0.26 percent, SingTel advanced 0.81 percent, United Overseas Bank fell 0.39 percent, Wilmar International eased 0.24 percent, Yangzijiang Shipbuilding jumped 1.42 percent and Keppel Corp, Thai Beverage, CapitaLand and Comfort DelGro were unchanged.

Telegram auto-delete message, expiring invites, and more

elegram is updating its messaging app with options for auto-deleting messages, expiring invite links, and new unlimited groups, the company shared in a blog post. Much like Signal, Telegram received a burst of new users in the confusion over WhatsApp’s privacy policy and now the company is adopting features that were already part of its competitors’ apps, features which offer more security and privacy. Auto-deleting messages were already possible in Telegram’s encrypted Secret Chats, but this new update for iOS and Android adds the option to make messages disappear in any kind of chat. Auto-delete can be enabled inside of chats, and set to delete either 24 hours or seven days after messages are sent. Auto-delete won’t remove every message though; if a message was sent before the feature was turned on, it’ll stick around. Telegram’s competitors have had similar features: WhatsApp introduced a feature in 2020 and Signal has had disappearing messages since at least 2016.

Code With HSN from in


Telegram Code With HSN
FROM USA